home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000082_lear@yeager.corp.sgi.com _Tue Mar 31 18:48:05 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <lear@yeager.corp.sgi.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA02572; Tue, 31 Mar 92 18:48:05 GMT+0100
  4. Received: by dxmint.cern.ch (cernvax) (5.57/3.14)
  5.     id AA08030; Tue, 31 Mar 92 19:43:27 +0200
  6. Received: from relay.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
  7.     for www-talk@nxoc01.cern.ch id AA05925; Tue, 31 Mar 92 09:42:46 -0800
  8. Received: from yeager.corp.sgi.com by relay.sgi.com via SMTP (911016.SGI/911001.SGI)
  9.     for @sgi.sgi.com:timbl@nxoc01.cern.ch id AA10133; Tue, 31 Mar 92 09:42:44 -0800
  10. Received: by yeager.corp.sgi.com (911016.SGI/911001.SGI)
  11.     for @sgi.com:cddev@sterling.com id AA14310; Tue, 31 Mar 92 09:42:43 -0800
  12. Date: Tue, 31 Mar 92 9:42:42 PST
  13. From: Eliot Lear <lear@yeager.corp.sgi.com>
  14. To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
  15. Cc: Edward Vielmetti <emv@msen.com>, www-talk@nxoc01.cern.ch,
  16.         cddev@sterling.com
  17. Subject: Re: Changing NNTP servers on the fly.
  18. In-Reply-To: Your message of Tue, 31 Mar 92 09:17:36 GMT+0200
  19. Message-Id: <CMM.0.90.2.702063762.lear@yeager.corp.sgi.com>
  20.  
  21.  
  22. Hello all,
  23.  
  24. It is true that the nntp working group has been pushing against all
  25. sorts of retrieval issues.  How any of the following would be
  26. implemented is completely an open question, right now.  I should say
  27. that much of what follows was the result of informal brainstorming,
  28. and a lot of discussion at various USENIXes.  I think everyone agrees
  29. that the NNTP people do not yet have enough information to make a
  30. decision, and there is a growing concern about scope of whatever
  31. project we would choose to take on, as one could quickly envision a
  32. very broad all-encompassing project that would serve everyone's needs
  33. but never be implemented.  As we begin to discuss best ways to present
  34. news to the user, we immediately come up against five questions.
  35. Briefly described, they are the following:
  36.  
  37. [1]    How shall the user select and receive new information?
  38.     Are we talking SQL or Z.39 or what?
  39.  
  40. [2]    Should the mechanism be a pull-update/lockstep mechanism, as
  41.     it is now, or does the server need to have enough smarts about
  42.     things like priorities such that the mechanism should be
  43.     async/interrupt driven?
  44.  
  45. [3]    Should we be writing the protocol with some sort of RPC
  46.     mechanism in mind, such that the application doesn't even know
  47.     if the service is local?
  48.  
  49. [4]    How do we handle archives?  Should a saved article be treated
  50.     just as any other article, or do we need stronger archive
  51.     search mechanisms in NNTP?  OR, should archive support be
  52.     placed in the netnews model, itself (e.g., sendme style
  53.     retrieval)?
  54.     OR, should netnews reading become a distributed model, as
  55.     access to the Internet approaches ubiquity?  Here is where
  56.     we begin to delve into resource and information location
  57.     issues.
  58.  
  59. [5]    Should whatever mechanism we design be limited to netnews, or
  60.     should we also leave enough rope for someone to use it for
  61.     mail?
  62.  
  63. So what we have right now is a growing list of questions, and not very
  64. many answers - YET.
  65.  
  66. I must clarify one point Tim made.  News is currently stored and read
  67. locally mostly for historical reasons.  The plain fact of the matter
  68. is that netnews has been and continues to be more popular than the
  69. Internet, simply because it costs less.  Thus in past people have not
  70. considered reading over the Internet as ``the mechanism'' because it
  71. could not be used as such by a large portion of the participants.
  72. There is also an issue of how to find new and interesting articles
  73. under a distributed model.  That's an area I haven't given much
  74. thought at all to.
  75.  
  76. The statement that the current NNTP is nothing more than a file
  77. transfer protocol is largely correct.  It's a specialized version that
  78. takes advantage of the netnews architecture.  In fact, it would have
  79. been quite possible to implement NNTP *in* FTP as an extension.
  80.  
  81. Eliot Lear
  82. [lear@sgi.com]
  83.  
  84.  
  85.